Java megzine: Java in Twitter by Michael Clarck & Manish Sahu

Author:Michael Clarck & Manish Sahu [Clarck, Michael]
Language: eng
Format: azw3
Publisher: UNKNOWN
Published: 2018-12-13T16:00:00+00:00

Download all listings in this issue as text in Listing 2, run takes no parameters and returns void, so there are no parameters and no return value. A Comparator<T>-based example, however, highlights this syntax a little more obviously, as shown in Listing 4. Remember that Comparator takes two strings and returns an integer whose value is negative (for “less than”), positive (for “greater than”), and zero (for “equal”).

If the body of the lambda

requires more than one expression, the value returned from the expression can be handed back via the return keyword, just as with any block of Java code (see Listing 5). (Where we put the curly braces in code such as Listing 5 will likely dominate Java message boards and blogs for years to come.) There are a few restrictions on what can be done in the body of the

lambda, most of which are pretty

intuitive—a lambda body can’t

“break” or “continue” out of the

lambda, and if the lambda returns

a value, every code path must

return a value or throw an excep

tion, and so on. These are much

the same rules as for a standard

Java method, so they shouldn’t be

too surprising.

Type inference. One of the features

that some other languages have

been touting is the idea of type

inference: that the compiler should

be smart enough to figure out

what the type parameters should

be, rather than forcing the develblogoper to retype the parameters.

Such is the case with the

Comparator example in

Listing 5. If the target type is a

Comparator<String>, the objects36

passed in to the lambda must be strings (or some subtype); otherwise, the code wouldn’t compile in the first place. (This isn’t new, by the way—this is “Inheritance 101.”)

In this case, then, the String declarations in front of the lhs and rhs parameters are entirely redundant and, thanks to Java 8’s enhanced type inference features, they are entirely optional (see Listing 6).

The language specification will have precise rules as to when explicit lambda formal type declarations are needed, but for the most part, it’s proving to be the default, rather than the exception, that the parameter type declarations for a lambda expression can be left out completely.

One interesting

side effect of Java’s lambda syntax is that for the first time in Java’s history, we find something that cannot be assigned to a reference of type Object (see Listing 7)—at least not without some help.

The compiler will complain that Object is not a functional interface, though the real problem is that the compiler can’t quite figure out which functional interface

SCOPE IT OUT

Lambdas are

lexically scoped,

meaning that a

lambda recognizes

the immediate

environment around

its definition as the

next outermost scope. this lambda should implement: Runnable or something else? We can help the compiler with, as always, a cast, as shown in Listing 8.

Recall from earlier that lambda syntax works with any interface, so a lambda that is inferred to a custom interface will also be inferred just as easily, as shown in Listing 9. Primitive types are equally as viable as their wrapper types in a

lambda type signature, by the way. Again, none of this is really new; Java 8 is just applying Java’s long-standing principles, patterns, and syntax to a new feature.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.